Wireless device positioning is a process of determining a device's coordinates in space. Once the coordinates are determined, they can be mapped to a certain place or address. Mapping and delivery of positioning information on request are parts of a location service that can be required for many purposes, such as basic emergency services.
Emergency services based on non-voice communication, e.g., Short Message Service (SMS) messaging, is under discussion in the Third Generation Partnership Project (3GPP) and in North America at the regulatory level. Non-voice communication can make emergency services feasible for people with speech disabilities or in threatening situations when voice communication with Public Safety Answer Point (PSAP) agents is not possible.
Of course, different services can have different positioning accuracy requirements. For example, positioning accuracy requirements for basic emergency services are typically defined by government regulatory agencies, such as the United States Federal Communications Commission, which regulates in the area of telecommunications.
A number of problems have been identified with prior solutions to providing positioning results for emergency services and other purposes. For example, it may not be possible to transfer a positioning result directly to a network element (e.g., a PSAP) because the receiving element may not support the format of the positioning result as it is reported. In such cases, the positioning result has to be converted from the unsupported format to a format that is supported, which can introduce unacceptable position error.
In the United States for example, applicable emergency call reporting standards, such as American National Standard for Telecommunications, “Emergency calling service”, T.1 628.2000 (R2005), and ANSI/J-STD-036-B, “Enhanced Wireless 9-1-1 Phase II” (May 2007), require the format of a positioning result delivered to PSAP equipment to be one of an ellipsoid point, an ellipsoid point with an uncertainty circle, and an ellipsoid point with an altitude and an uncertainty circle. Those three formats are only three of the seven formats used in communication networks specified by the 3GPP, and so the positioning result format conversion typically must be used for emergency services.
Shape conversion for positioning aims at transforming a positioning result from a given format (e.g., a Geographical Area Description (GAD) shape specified in 3GPP Technical Specification (TS) 23.032) to either a supported format (e.g., a format required by a PSAP) or a requested format at a required confidence level (e.g., typically 95% for a PSAP) such that the confidence of the transformed positioning result is at the required level. In practice, guaranteeing the same uncertainty at the same confidence before and after transformation is not possible in most of the cases, which is to say that the uncertainty of the transformed result is typically greater than that of the original result.
For example, an AECID positioning method described below typically delivers a positioning result and uncertainty in a polygon format, which must be converted to a circle covering the polygon in the best way before it is delivered to a PSAP or similar user. The AECID positioning result could be describing a long street between buildings, and so after format conversion, the positioning result could be transformed into a large circle covering both the street and the inside of the buildings.
Methods of transforming a positioning result from an ellipsoid arc format, an ellipsoid point with an uncertainty ellipse format, or an ellipsoid point with an altitude and uncertainty ellipsoid format to an ellipsoid point with an uncertainty circle format are described in T. Wigren et al., “Emergency Call Delivery Standards Impair Cellular Positioning Accuracy”, IEEE ICC 2010, May 2010. The conversion methodology described there seeks to minimize the radius of the uncertainty circle, subject to the constraint that the original positioning shape (e.g., an ellipsoid arc) is covered by the uncertainty circle. Thus, a circle circumscribing the original positioning shape is to be found.
FIG. 1A depicts an example of the conversion methodology in Wigren et al., showing orthogonal distances from a radio base station (RBS) on the horizontal and vertical axes. In FIG. 1A, the position of the RBS is plotted as a star 101, and for a positioning ellipsoid arc 103, the center of the circumscribed uncertainty circle 105 is plotted as a point 107. The possibility of errors introduced by transforming a positioning result in the ellipsoid arc format to a positioning result in an ellipsoid point with an uncertainty circle format should be clear from FIG. 1A.
FIGS. 1B, 1C illustrate quantitative estimates of accuracy loss introduced by transforming a positioning result from one format to another. FIG. 1B is a plot of accuracy loss as a ratio of the areas of an uncertainty circle and a circumscribed ellipsoid arc with respect to distance from an RBS, for urban, suburban, and rural cells with radii of 500 m, 5 km, and 50 km, respectively. FIG. 1C is a plot of accuracy loss as a ratio of the areas of an uncertainty circle and a circumscribed ellipse with respect to a ratio of the semi-major and semi-minor axes of the ellipse. In both cases, the accuracy loss increases with the aspect ratio of the ellipse.
Moreover for different formats with different uncertainty information, different statistical models for describing positioning results within an area typically apply, e.g., a uniform distribution for polygons and ellipsoid arcs, but a two-dimensional (2-D) Gaussian probability distribution for uncertainty ellipses. Hence, even if the distributions could be taken into account when converting one format to another, the conversion would still cause information loss and introduce additional positioning errors.
Other problem areas that require positioning result format conversion include that currently it is not possible to send positioning results to a PSAP in native civic address formats and to signal the results directly from a PSAP to field agents (e.g., police officers and fire fighters). PSAPs typically do not dispatch emergency personnel to geographical coordinates but rather provide them with a street address. It is possible that a positioning result is already in a human-readable format, e.g., a civic address format, but the human-readable format may not be supported by the communication network, or the human-readable format may not be supported by the PSAP. Thus, transformation to an acceptable format and then back to a human-readable format is necessary for communicating the information to PSAP agents, introducing positioning errors.
Another problem area is that not all 3GPP positioning result formats include positioning uncertainty information. For example, a polygon format supported by 3GPP networks provides uncertainty information only implicitly, and so for such formats, there is no way to signal the positioning uncertainty information when necessary. Currently standardized positioning result formats, e.g., a polygon limited to fifteen vertices, can also be insufficient for hybrid positioning methods, which are expected to become important in 3GPP Long Term Evolution (LTE) communication networks. Hybrid positioning methods can yield positioning results that may be combinations of arcs, ellipses, polygons, etc. In most cases, such a result could not be represented by just one of any of the standardized GAD shapes. To comply with the standard, a polygon with more vertices representing more accurate positioning information could have to be converted to a polygon with the required fewer vertices, which in most cases means accuracy loss.
There is also currently no simple solution for communicating a positioning result, including uncertainty information, by device-to-device communication, e.g., mobilephone-to-mobilephone communication. Commercial examples where such communication would be useful include friend-finding and tracking the whereabouts of children, e.g., for safety reasons.
The Universal Mobile Telecommunication System (UMTS) is a third-generation (3G) mobile communication technology designed to succeed GSM. LTE is a UMTS successor that improves the UMTS in terms of higher data rates, improved efficiency, and lowered costs, among others. A Universal Terrestrial Radio Access Network (UTRAN) is the radio access network of a UMTS, and an Evolved UTRAN (E-UTRAN) is the radio access network (RAN) of an LTE system.
FIG. 2A depicts a communication network 200 with an E-UTRAN, in which a user equipment (UE) 210, such as a mobile telephone or other wireless communication device, is wirelessly connected to an RBS 220a, which in LTE is commonly called an evolved NodeB (eNodeB). The E-UTRAN shown in FIG. 2A has three eNodeBs 220a, 220b, 220c, each of which serves one or more areas, or cells, 230a, 230b, 230c, and is connected to a core network of the network 200. In an LTE network, the eNodeBs 220a-c are connected to a Mobility Management Entity (MME) 240 in the core network.
In this application, the UE 210 can be a mobile telephone; a pager; a headset; a tablet, netbook, or laptop computer; a small radio node or base station, such as for a home; a relay node; a sensor; etc., which as a device or node being positioned can also be called a Location Service (LCS) target.
Each eNodeB 220a, 220b, 220c serves a respective geographical area that is divided into one or more cells. An eNodeB can use one or more antennas at one or more sites to transmit information into its cell(s), and different antennas can transmit respective, different pilot, position reference, and other signals. Neighboring eNodeBs may be coupled to each other by an X2-protocol interface that supports active-mode mobility of the UEs. An eNodeB controls various radio network functions, including for example single-cell radio resource management (RRM), such as radio access bearer setup, handover, UE uplink/downlink scheduling, etc. Multi-cell RRM functions can also use the X2-protocol interfaces. Each eNodeB also carries out the Layer-1 functions of coding, decoding, modulating, demodulating, interleaving, de-interleaving, etc., and the Layer-2 retransmission mechanisms, such as hybrid automatic repeat request (HARQ).
In FIG. 2A, the MME 240 is connected to a positioning node 250, which can also be called a location server. The positioning node is a physical or logical entity that manages positioning for an LCS target, such as the UE 210. In a control-plane architecture, the positioning node 250 can be called an Evolved Serving Mobile Location Center (E-SMLC). As illustrated in FIG. 2A, the E-SMLC can be a separate core network node, but it can also be a functionality integrated in another network node. In a user-plane architecture, the positioning node 250 can be called a Secure User Plane Location (SUPL) Location Platform (SLP).
The LTE Positioning Protocol (LPP) and LTE Positioning Protocol annex (LPPa) are protocols used for carrying out positioning in the control-plane architecture in LTE. The LPP is also used in the user-plane architecture, and the LPPa can be used to support user-plane positioning. There can also be LPP extensions, e.g., LPPe, which can be included in LPP messages. Upon receiving a positioning request, the E-SMLC can receive positioning-related parameters from an eNodeB via the LPPa. The E-SMLC then assembles and sends assistance data and the request for the positioning or positioning measurements to the target wireless device, e.g., a UE, via the LPP.
FIG. 2B depicts an example of a control-plane architecture and protocols and FIG. 2C depicts an example of a user-plane architecture and protocols of a positioning system in an LTE network 200. In the control plane, a UE communicates with the E-SMLC 250 transparently via an eNodeB and an MME over the LPP, and the eNodeB communicates with the E-SMLC transparently via the MME over the LPPa. In the user plane, the LPPa protocol is not used, although the 3GPP allows for the possibility of inter-working between the control- and user-plane positioning architectures. There may or may not be an interface between the E-SMLC and the SLP. In the user-plane positioning architecture, the SUPL service, which is a lower layer for the LPP, uses established data-bearing channels (i.e., the LTE user plane) and positioning protocols (i.e., LPP) for exchanging positioning information between a LCS target (e.g., a UE) and a LCS server (e.g., a SLP). In the user-plane architecture, the UE 210 can be more precisely called a SUPL-enabled terminal (SET).
Thus, the LPP is a point-to-point protocol between an LCS server, such as the E-SMLC, and an LCS target, such as the UE, that is used to position the target. Transmitted LPP messages are transparent to the MME, and use radio resource control (RRC) protocol messages for transport over an LTE-Uu interface between the UE and the eNodeB, and then 51 application protocol (S1AP) messages over an S1-MME interface between the eNodeB and the MME, and then LCS-AP messages over an SLs interface between the MME and the E-SMLC. LPP is defined in 3GPP TS 36.355 V9.2.1, LTE Positioning Protocol (LPP) (Release 9) (June 2010), for example.
The LPPa is a protocol for the interface between an eNodeB and the positioning node, such as the E-SMLC. LPPa messages are also transparent to the MME, which routes LPPa message packets over the S1-MME and SLs interfaces without knowledge of the involved LPPa transactions. The eNodeB may also be unaware of the information carried by an LPPa message or the corresponding UE, although the eNodeB may be aware of the fact that there is a transaction as the message can be received and forwarded. With interworking between the control and user planes, LPPa can assist the user plane by querying eNodeBs for information and eNodeB measurements not related to a UE connection. LPPa is defined in 3GPP TS 36.455 V9.2.0, LTE Positioning Protocol A (LPPa) (Release 9) (June 2010), for example.
Positioning Methods and Positioning Results
An LTE network can implement a variety of complementary positioning methods that have different performances in different environments. Depending on where positioning measurements are made and the final positioning result that is calculated, the methods can be UE-based, UE-assisted, or network-based, and each has its own advantages.
In some environments, a positioning result can be accurately determined by using positioning methods based on a Global Positioning System (GPS). Nowadays, networks often are also able to assist a UE in order to improve the device's receiver sensitivity and GPS start-up performance, as in, for example an Assisted-GPS (A-GPS) positioning method. Another terrestrial positioning method, called Observed Time Difference of Arrival (OTDOA), has been standardized by the 3GPP to remedy some of the problems with GPS and A-GPS.
In addition to UE-assisted OTDOA, the 3GPP LTE network specifications also define methods, procedures, and signaling support for Cell Identity (CID); UE-assisted and network-based Enhanced CID (E-CID); and UE-based and UE-assisted Assisted-Global Navigation Satellite System (A-GNSS), including A-GPS. Uplink Time Difference of Arrival (UTDOA) is also under consideration for LTE networks.
CID Positioning
Given the cell ID of a UE's serving cell, the UE position corresponds to the cell coverage area, which can be described, for example, by a pre-stored polygon, where the cell boundary is modeled by a set of non-intersecting polygon segments connecting all the corners.
E-CID Positioning
E-CID positioning exploits four sources of positioning information: the CID and the corresponding geographical description of the serving cell, the round trip time (RTT) with respect to the serving cell (measured, for example, by a timing advance (TA) of the serving cell and/or receive-transmit (Rx-Tx) time difference measured at either the UE or the RBS), the CIDs and corresponding signal measurements of other cells (up to 32 cells in LTE, including the serving cell), as well as network-based angle of arrival (AoA) measurements.
UE received-signal measurements that can be utilized for E-CID in LTE include carrier Received Signal Strength Indicator (RSSI), Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), and UE receive-transmit (Rx-Tx) time difference. The E-UTRAN measurements available for E-CID are eNodeB Rx-Tx time difference, TA Type 1 corresponding to (eNodeB Rx-Tx time difference)+(UE Rx-Tx time difference), TA Type 2 corresponding to eNodeB Rx-Tx time difference, and uplink (UL) AoA. UE Rx-Tx measurements are typically used for the serving cell, and for example RSRP and RSRQ as well as AoA can be utilized for any cell and can also be conducted on a frequency different from that of the serving cell. UE E-CID measurements are reported by the UE to the positioning server over the LPP, and the E-UTRAN E-CID measurements are reported by the eNodeB to the positioning node over the LPPa.
Three common E-CID positioning methods include: CID+RTT, CID+signal strength, and AoA+RTT. Measurements from multiple cells can also be used with E-CID. The positioning result of CID+RTT includes a positioning shape that is typically an ellipsoid arc describing the intersection of the cell polygon and a circle corresponding to the RTT. A typical result of the signal-strength based E-CID positioning includes a positioning shape that is a polygon since the signal strength is subject to fading effects, for example, and therefore often does not scale exactly with the distance. A typical positioning shape of AoA+RTT positioning is an ellipsoid arc describing the intersection of a sector limited by AoA measurements and a circle from the RTT-like measurements.
OTDOA Positioning
With OTDOA, an LCS target such as a UE measures timing differences for downlink reference signals received from multiple distinct locations. For each measured neighbor cell, the UE measures Reference Signal Time Difference (RSTD) which is the relative timing difference between a neighbor cell and the reference cell. The UE positioning result is then found as the intersection of hyperbolas corresponding to the measured RSTDs. At least three measurements from geographically separated RBSs with a good geometry are needed to solve for two coordinates of the UE. In order to find the UE position, knowledge of RBS locations and transmit timing offsets is needed. The positioning calculations can be conducted, for example, by the positioning node, such as the E-SMLC or the SLP in LTE, or by the UE. The former approach corresponds to UE-assisted positioning, and the latter corresponds to UE-based positioning.
In UTRAN Frequency Division Duplex (FDD), system frame number (SFN) measurements can be used for positioning. In particular, an SFN-SFN type 2 measurement performed by the UE can be used for OTDOA positioning. That measurement is the relative timing difference between cells based on the primary Common Pilot Channel (CPICH) transmitted by the cells. The UE-reported SFN-SFN type 2 can be used by the network to determine the UE position.
Other Positioning
Hybrid positioning, fingerprinting positioning, and assisted E-CID (AECID) do not require additional standardization by 3GPP and are therefore also possible in an LTE network. Furthermore, there can also be UE-based versions of the methods described above, e.g., UE-based GNSS (e.g., GPS) or UE-based OTDOA, etc. There can also be alternative positioning methods, such as civic-address-based positioning, which is described in U.S. patent application Ser. No. 12/871,984 filed on Aug. 31, 2010, although it can be noted that messaging supporting civic-address-based positioning is not yet standardized by 3GPP.
In fingerprinting and AECID positioning, the typical format of a positioning result is a polygon because both methods typically involve received signal measurements, CID, etc. In TDOA-based and TOA-based methods (e.g., OTDOA, UTDOA, and GNSS/A-GNSS), a typical format of the positioning result is an ellipsoid point with uncertainty circle/ellipse/ellipsoid, which is the result of intersection of multiple hyperbolas/hyperbolic arcs (e.g., OTDOA) or circles/arcs (e.g., UTDOA, GNSS, and A-GNSS).
A hybrid positioning method is any combination of the positioning methods described above, and so the positioning result can typically have any shape or format. Nevertheless, the positioning result of a hybrid positioning method in many cases is likely to have a polygon as the positioning shape.
It will be appreciated that other networks, e.g., UMTS, GSM, and cdma2000 networks, also typically support a variety of positioning methods that are equivalent to those described above.
Positioning Result Formats
Table 1 shows the positioning result formats that are included in the 3GPP network specifications. Each format is associated with a GAD shape, such as one of the seven GAD shapes specified in 3GPP TS 23.032, for example, Section 5 of 3GPP TS 23.032 V8.0.0, Universal Geographical Area Description (GAD) (Release 8) (December 2008). The shapes/formats in Table 1 apply for LTE, UMTS, and GSM networks, and equivalent formats can be used in other networks.
TABLE 1Positioning result reporting formats in 3GPPPositioning IncludesIncludesresult formatDescriptionuncertaintyconfidencePolygonThe polygon format is describedYes*Noby a list of 3-15 latitude, longitudecorners, encoded in WGS 84 co-ordinates. This format may beobtained by application of cell IDpositioning in LTE.Ellipsoid The ellipsoid arc is described by a YesYesarccenter point (eNodeB antennaposition), encoded as latitude,longitude in WGS 84 co-ordinates.Furthermore, the format containsan inner radius of the arc, athickness of the arc as well as theoffset angle (clockwise from north)and the included angle (openingangle). Together, theseparameters define a circularsector, with a thickness and withleft and right angles. This formatis e.g. produced by cell ID + TApositioning in LTE.Ellipsoid The ellipsoid point format isNoNopointdescribed by a center point,encoded as latitude, longitude inWGS 84 co-ordinates.Ellipsoid The ellipsoid point withYesNopoint withuncertainty circle format consistsuncertainty of a center point, encoded ascirclelatitude, longitude in WGS 84 co-ordinates, in combination with anencoded radial uncertainty radius.Ellipsoid The ellipsoid point withYesYespoint withuncertainty ellipse format consistsuncertainty of a center point, encoded asellipselatitude, longitude in WGS 84 co-ordinates. The uncertainty ellipseis encoded as a semi-major axis,a semi-minor axis and an anglerelative to north, countedclockwise from the semi-majoraxis. This format is typicallyproduced by OTDOA and A-GPSpositioning in LTE.Ellipsoid The ellipsoid point with altitudeNoNopointformat is encoded as an ellipsoidwith altitudepoint, together with an encodedaltitude.Ellipsoid This is the format commonlyYesYespoint received from A-GPS capablewith altitude terminals. It consists of anandellipsoid point with altitude and anuncertainty uncertainty ellipsoid, the latterellipsoidencoded with a semi-major axis, asemi-minor axis, an angle relativeto north, counted clockwise fromthe semi-major axis, together withan uncertainty altitude. Thisformat is typically produced by A-GPS positioning in LTE.*uncertainty information for polygon format is included implicitly, but not explicitly, as with the arc, for example, where there are two radii, and hence it is not clear whether the polygon is large due to a large uncertainty or the positioning result itself gives a large polygon
The civic address format described above organizes civic address information identifying the physical geographical location of a network node, described with at least some of the conventional fields such as street, city, postal code, etc. An example of a civic address format is depicted in the following Table 2, where in practice each field typically is also associated with a short name or label. Other formats of representing the address information can, of course, be used. For multi-network compatibility, the address message format in 3GPP or 3GPP2 can also follow, for example, the format defined by IETF, or have a conversion interface to it.
TABLE 2Civic Address Information FormatField PresenceDefaultField DescriptionField Type(optional/mandatory)valueApartment/office/suite16OptionalNo datanumber/floor number alpha/numericStreet number16OptionalNo dataalpha/numericStreet name32OptionalNo dataalpha/numericCity name32OptionalNo dataalpha/numericState/province name32OptionalNo dataalpha/numericPostal code16OptionalNo dataalpha/numericRoad8OptionalNo dataalpha/numericComment (for64OptionalNo dataexample: “northeast alpha/numericcorner outside Mainconference room”)
In Table 2, at least some of the Information Elements (IEs) defining the civic address format are hierarchical, with “lower” levels of hierarchy defining location with greater specificity, and “higher” levels of hierarchy defining location more generally, or with greater uncertainty. For example, a city is a more specific location than a state; a street name is more specific than a city; a street number with the street name is more specific still; etc. In this sense, the hierarchical level of an IE in the civic address format inherently carries uncertainty information. A positioning request can be tailored to a specific level of accuracy by specifying the IEs, or the highest hierarchical level IE, to be provided. This allows applications to tailor positioning requests to the level of accuracy desired, and reduces unnecessary signalling since the full civic address (i.e., any hierarchical level higher than that requested) need not be transmitted, or propagated through the network.
Similar to other positioning result formats, the positioning information in a civic address format can be complemented with at least one of the uncertainty and the confidence information, where in one embodiment the uncertainty information can be represented by a polygon format (e.g., one of the GAD shapes).